I'd strongly recommend using declare in your workaround guidance instead of !, because ! is not forward-compatible with the ES spec (see here for details).

Is declare forward compatible with the ES spec? I could not find a reference to it in the ECMA262.

Yeah. The reason is a bit subtle; the forward compatibility here is not "will this thing be allowed in this position?" (to which the answer is "who knows but probably no" for both of them!), but rather "what are the semantics of the field created this way?"

For !, it creates and initialized the property as undefined using defineProperty in the constructor, which stomps any storage that was already there (via the prototype, a superclass etc.) and is very sensitive to the order of the operations which modify the class field as a result. That is "correct" in that it's how a class field with no initializer is specced but it's basically never what you want when working with a decorator.

declare simply no-ops the actual field creation from TS's side, until the decorator does its job and creates it with its own details; there's never a defineProperty call which initializes the field as undefined in that flow. That means that you can safely use declare for any instance of this kind of thing and you'll always get the right behavior. Also, that's true whether you emit your compiled JS using TS itself or using Babel!

All good – thanks for getting back around to it. (I have more than a few long-standing PRs to get back to on things I maintain myself. 😂)